One type of electronic design automation (EDA) tool is a hardware-based functional verification system. Examples of a hardware-based functional verification system are hardware logic emulation systems and simulation acceleration systems. Hardware logic emulation systems and simulation acceleration systems are collectively referred to as emulation systems in the subsequent sections. Emulation systems are used to verify the functionalities of electronic circuit designs prior to fabrication as chips or as electronic systems. Such emulation systems are commercially available from various vendors, such as Cadence Design Systems, Inc. headquartered in San Jose, Calif.
Typical emulation systems utilize either interconnected programmable logic chips or interconnected processor chips. Examples of hardware logic emulation systems using programmable logic devices are disclosed in, for example, U.S. Pat. No. 5,109,353, entitled “Apparatus for emulation of electronic hardware system,” U.S. Pat. No. 5,036,473 entitled “Method of using electronically reconfigurable logic circuits,” U.S. Pat. No. 5,475,830 entitled “Structure and method for providing a reconfigurable emulation circuit without hold time violations,” and U.S. Pat. No. 5,960,191 entitled “Emulation system with time-multiplexed interconnect.” U.S. Pat. Nos. 5,109,353, 5,036,473, 5,475,830 and 5,960,191 are incorporated herein by reference. Examples of hardware logic emulation systems using processor chips are disclosed in, for example, U.S. Pat. No. 5,551,013 entitled “Multiprocessor for hardware emulation,” U.S. Pat. No. 6,035,117 entitled “Tightly coupled emulation processors,” and U.S. Pat. No. 6,051,030 entitled “Emulation module having planar array organization.” U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030 are incorporated herein by reference.
A design under test (DUT) for emulation is usually provided in the form of register transfer level (RTL) description or gate-level netlists (or “netlists”). It is appreciated that DUTs, electronic circuit designs, user circuit designs, and user designs are exchangeably used in the present application without causing confusion. Using a method called synthesis, gate-level netlists are derived from RTL sources including a hardware description language (HDL), such as Verilog or VHDL. RTL and/or gate-level netlists describe circuit components and electrical interconnections between the circuit components. The circuit components include circuit elements, such as combinatory logic (e.g., gates) and sequential logic (e.g., flip-flops, latches), and memory elements (e.g., SRAM, DRAM) necessary for implementing user designs.
One primary use for hardware logic emulation systems is debugging user designs. Thereby, any functional errors present in the user designs can be identified and resolved prior to fabrication of the user designs in actual silicon. Circuit designers have used hardware emulation systems for many years to perform such debugging because the alternatives, such as simulation, typically are much slower than emulation. Simulation is a software based approach; whereas, for emulation, the user design is compiled with a testbench to form a machine-executable model. Typically, the testbench is represented as a target system (or board) that can directly interact with the user design. The machine-executable model, once compiled, can be executed via a workstation or personal computer.
To facilitate compiling the machine-executable model, the user design usually is provided in the form of a netlist description. The netlist description describes the components of the user design and the electrical interconnections among the components. The components include each circuit element for implementing the user design. Exemplary conventional circuit elements are combinational logic circuit elements (or gates), sequential logic circuit elements, such as flip-flops and latches, and memory elements, such as static random access memory (SRAM) and dynamic random access memory (DRAM). Memory elements that are incorporated into the user design often are referred to as being “design memory systems.” The netlist description can be derived from any conventional source, such as a hardware description language (HDL), and is compiled to place the netlist description in a form that can be used by the emulation system.
A co-simulation environment of a hardware emulation system provides a user with a capability to interrupt hardware emulation at an opportune time to debug the user's design. A host system typically runs a testbench with software variables, breakpoints, and other variables interacting with the user design under test (DUT). The hardware emulation system runs at or near the speed of the real hardware while the simulation speed is orders of magnitude slower.
A host system may simultaneously run multiple user's processes independently of each other. Each process may be run by a different user, or a user can run multiple processes. Multi-user or multi-process access is useful for simultaneous block-level verification by team members. Particularly, later in the design cycle, as the team assembles blocks of the design into a full chip, they can accelerate the entire design by dynamically allocating capacity to the team members.
In order to allow multiple users or multiple processes to share a hardware emulation system, a switching device is used to interface a hardware emulation system to control access to the hardware. The access control is typically implemented in a device driver. In this approach, multiple users (or processes) simultaneously open the device driver, and rely on the ‘good behavior’ of the software that a user is running not to disturb other user's process. However, if the user's software does not behave well, for example due to a software bug, misuse of a device driver, or even by ill-intention, the device may not operate as the user intends or the user's information may be leaked to other users unintentionally.
To resolve the issue with a device driver of a switching device, access functions may be implemented to provide controlled access to the device. The driver's access functions determines when or in which order the device can be accessed by one process safely. The driver functions may need to swap hardware control registers to switch from a user's process to another user's process. However, this approach increases the complexity of the device driver, thus increases the time-to-market because such a complex device driver is more difficult to design, implement and debug. In addition, access functions introduce runtime overhead to the user's process when accessing the device since every access would involve context switching from the user's process to OS kernel and back to the user's process in addition to the increased execution time for executing the access functions and the hardware register swapping.
In view of the foregoing, a need exists for a system and method for providing multi-process protection that overcomes the aforementioned obstacles and deficiencies of currently available hardware-based functional verification systems.